前言

近幾年，大型語言模型（Large Language Model，LLM）快速進入日常工作。它可以協助我們整理文章、產生程式碼、翻譯內容、摘要會議紀錄，也能用自然的語氣回答各種技術問題。當我們第一次看到模型產生一段流暢又完整的回答時，很容易產生一種錯覺：只要把問題描述得夠清楚，模型就一定知道答案。

但語言流暢和內容正確，其實是兩件不同的事。LLM 的核心工作是根據上下文預測接下來最合理的文字，它並不是一個永遠保持最新、每次都能查證來源的資料庫。當模型遇到訓練資料中沒有的內容、版本已經改變的技術，或描述不夠清楚的問題時，仍然可能產生語法正確、語氣肯定，卻不符合事實的說明。

例如，我們詢問模型某個框架的設定方式，它可能混合不同版本的文件；詢問 pandas 有沒有 read_markdown() 這個函式，它可能參考 read_csv()、read_json() 的命名模式，產生一份參數齊全、範例完整、實際上卻無法執行的說明——因為這個函式根本不存在。這些錯誤通常不會以「我不確定」的形式出現，而是被包裝成完整步驟。這種現象通常被稱為幻覺（Hallucination），也是實際導入 LLM 時不能忽略的風險。

這次 iThome 鐵人賽，我想用 30 天完成一個繁體中文技術知識助理，系列名稱是「讓 LLM 說話有憑有據：打造 RAG 知識助理」。我希望它回答問題時引用實際文件，知識庫沒有相關內容時承認資料不足，並且能透過評測資料檢查搜尋與回答品質。

LLM 為什麼需要外部知識？

我們可以把 LLM 想成一個非常擅長整理與生成文字的模型，但不能把它直接當成某個專案的官方文件或企業內部知識庫。模型在訓練階段學到的是大量文字中的語言模式與關聯，這些知識會以參數形式存在模型裡。當我們更新公司規範、替換套件版本，或新增一份私人文件時，模型不會自動知道這些變化。

另一個問題是，模型回答時使用了哪些內容通常不容易追溯。即使答案碰巧正確，我們也可能無法確認它是根據哪一份文件、哪個版本或哪段內容得出的。如果答案要交給同事使用，或放進正式系統中，往往還需要人工重新查證。

因此，一個實用的知識助理不能只追求「回答得像人」，還需要讓回答和指定的知識來源建立關係。使用者不只想知道答案，也想知道答案來自哪裡；系統不只要能夠回答，也要在資料不足時知道自己不應該回答。

RAG 解決什麼問題？

RAG 的全名是 Retrieval-Augmented Generation，中文通常翻譯為「檢索增強生成」。它的核心想法是在 LLM 產生回答之前，先從外部知識庫搜尋與問題相關的內容，再把搜尋結果提供給模型作為上下文。模型接著根據這些內容整理答案，而不是完全依賴自己原本記得的資訊。

以技術知識助理為例，使用者詢問 Spring Security 中的 SecurityFilterChain 時，系統會先從 Markdown 筆記或技術文件中搜尋相關段落。搜尋元件找到內容後，系統再把問題、文件片段與回答規則交給 LLM，最後列出使用到的文件標題、段落或來源連結。

這個流程可以分成兩個部分。第一部分是 Retrieval，也就是從知識庫找到正確且相關的資料；第二部分是 Generation，也就是讓 LLM 根據資料組織出使用者看得懂的回答。前者決定模型拿到什麼，後者決定模型如何表達，兩者都會影響系統品質。

為什麼不直接使用 Prompt 或 Fine-tuning？

文件很少時，直接把內容放進 Prompt 確實可行。但當資料量增加，Prompt 會變得過長，搜尋、更新與管理也會越來越困難；每次提問都傳送整批文件，還可能增加延遲與成本。Fine-tuning 則比較適合改變模型的回答風格、格式或特定任務行為，不一定適合保存經常更新的文件內容。RAG 的優點是可以獨立更新知識庫，而不必重新訓練模型。

當然，RAG 也不是萬靈丹。它可能搜尋到不相關的段落，也可能因為文件切分不當而遺失上下文；如果知識庫本身有錯誤，模型仍然可能產生錯誤答案。因此，本系列不只會把 RAG 串起來，也會觀察資料處理、搜尋策略與回答規則之間的關係。

這個系列的特色

本系列會以繁體中文技術資料作為主要實驗對象。中文文件的斷詞、標點、專有名詞、版本名稱與段落結構，都可能影響搜尋結果，因此會從文字清理與文件切分開始，逐步比較不同方法的差異。

系列也會保留傳統 NLP 與資訊檢索的基準，不會一開始就使用向量搜尋。我們會先實作關鍵字搜尋、TF-IDF 與 BM25，再比較 Embedding 與 Hybrid Search 是否帶來實際改善。最後還會建立問題與標準文件，檢查搜尋是否找對資料、回答是否忠實使用來源，以及沒有答案時能否正確拒答。

這 30 天會怎麼進行？

前十天會聚焦在問題定義、知識庫與傳統搜尋。我們會準備繁體中文技術文件，處理文字清理、斷詞與文件切分，再用關鍵字搜尋、TF-IDF 與 BM25 建立基準。這個階段的目標不是做出華麗介面，而是先確認系統能不能找到真正相關的內容。

接下來會進入 Embedding 與向量搜尋，理解文字如何被轉換成向量，以及向量資料庫如何儲存和查詢結果。我們會比較關鍵字搜尋與語意搜尋，並嘗試 Hybrid Search 與 Reranker，看看如何同時處理專有名詞與語意相近的問題。

中後段會正式串接 LLM，建立上下文組合、Prompt 設計、回答生成與來源引用；接著處理資料不足時的拒答、問題改寫與多輪對話。最後幾天會分析搜尋命中率、回答正確性、引用可靠度與常見失敗案例，並討論 Prompt Injection、惡意文件、API 化與基本測試。

最後想完成的作品

30 天結束時，我希望得到的不是只能展示畫面的聊天機器人，而是一條可以理解、測試與改進的 NLP + LLM 流程。使用者提出問題後，系統會從繁體中文知識庫找出相關段落，交給 LLM 產生回答並列出引用來源；如果知識庫沒有足夠資訊，系統會清楚表示目前無法確認，而不是勉強編出一個答案。

為了讓主線能在 30 天內完成，本系列暫時不加入 Fine-tuning、多模態模型、複雜 Agent、PDF OCR 或大規模分散式部署。不是因為這些技術不重要，而是每個主題都足以發展成另一個系列。這次的核心目標很單純：從文字處理開始，完成一個可以搜尋、回答、引用與評測的繁體中文 RAG 系統。

接下來，先把問題定義清楚：這個助理要服務誰、回答哪些類型的問題、資料範圍到哪裡，以及我們要如何判斷它是否真的回答得好。